-
Notifications
You must be signed in to change notification settings - Fork 8.1k
drivers: usb: udc: stm32: fixes around control endpoint/transfers #97729
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
drivers: usb: udc: stm32: fixes around control endpoint/transfers #97729
Conversation
Drop all existing transfers in control endpoints' queue when a new SETUP packet is received. Also use the appropriate net_buf API in a nearby place. Signed-off-by: Mathieu Choplain <[email protected]>
During a Host-to-Device Control transfer, an arbitrary amount of data is sent from Host to the Device using OUT Data packets. If the total amount of data to transfer, communicated via the wLength field of the SETUP packet, exceeds the EP0 MaxPacketSize, several Data packets until all data has been transfered. Combined with HAL behavior, the STM32 driver did not handle this situation properly and always ended reception after a single Data packet was received regardless of whether or not all data had actually been received from Host. Modify driver to handle this situation properly by keeping track of how much data has been received and restarting transfers until we have received everything the Host promised it would send. Signed-off-by: Mathieu Choplain <[email protected]>
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM AFAICT.
For each board, nucleo_l552ze_qBuild command:
Running the suite several times reveals spurious failures on test 12 / 21:
nucleo_c071rbBuild command:
b_u585i_iot02aBuild command:
nucleo_u5a5zj_qBuild command: Full-Speed (though
High-Speed:
stm32n6570_dkBuild command: Full-Speed:
High-Speed:
stm32h747i_disco//m7Full-Speed:
High-Speed:
Summary:
I need to perform additional tests on |
First commit is similar to what was introduced by #94001 - in my testing, it doesn't seem necessary, but I've included it in this patchset regardless. (I allowed myself to "cherry-pick" it as @nandojve seems unavailable)
Second commit fixes the same issue as #94001 but in a different manner that is, I believe, more solid.
Full testing TBD, but preliminary results show I have same
testusb
results as with #94001.